Various classes of block diagrams describe computations that can be performed on application-specific computing hardware, such as a computer, microcontroller, FPGA, and custom hardware. Classes of such block diagrams may include time-based block diagrams such as those found within Simulink® from The MathWorks, Inc. of Natick, Mass., state-based and flow diagrams such as those found within Stateflow® from The MathWorks, Inc. of Natick, Mass., and data-flow diagrams. A common characteristic among these various forms of block diagrams is that they define semantics on how to execute the diagram.
Models for complex systems arising in applications domains, such as automotive, aerospace, and communication engineering, are generally developed in a modular fashion allowing them to be used in more than one design project. For instance, while developing an automobile the overall model consists of similar modules, such as an engine module, an engine controller module, a suspension module, a dynamic suspension controller module, etc., regardless of the specific model of the automobile. The main differences arise in how each of the modules in the overall model is configured to obtain a final system level specification of the particular automobile model.
Conventional block diagram modeling environments provide certain mechanisms for allowing users to configure and deploy different configurations for a given model. FIG. 1A depicts an exemplary mechanism for configuring and deploying different configurations in the conventional block diagram modeling environment. The exemplary mechanism utilizes a configurable subsystem that allows users to define several different implementations for a given module in a block diagram via a subsystem within a library 1910. The model designer may define different configurations for the module within the library 1910. In this example, the model designer defines three different signal sources, Ramp, Sine Wave, and Pulse Generator, within the library 1910. Within the library 1910, the designer introduces a special ‘Master’ block 1920 that configures a standard connectivity interface for the family of the configurations in the library 1910. The Master block 1920 may be configured to include connectivity interfaces for the three signal sources. Once configured, the Master block 1920 becomes a template configurable subsystem that can be dragged into any model. Within the host model 1930, users can then choose between the different subsystems, such as the three signal sources, in the library 1910 by right-clicking on the template block. In this example, Ramp is selected for the configurable subsystem.
The main advantage of configurable subsystems is that they have little or no performance penalty on the execution of the block diagram. Only the active configuration is present in the block diagram once the model has been compiled. However, this mechanism does have the following drawbacks:
1. The configurable subsystem must reside within a library and cannot be placed directly within a model. Thus, there is no way to directly specify a different configuration for a model, only indirectly via libraries.
2. There is reduced syntactic clarity and usability in the block diagrams because users cannot see all of the available configurations in the host model.
3. Users are offered no mechanism for saving away the active configurations. They are constrained to always bundling the model with the library containing all configurable subsystems.
4. Model builders are constrained to using subsystems to represent their model configurations. Hence they do not have the flexibility of using cascades of blocks for each configuration. Such cascades may sometimes be desirable in order to shed more light on the system that is being modeled.
In another conventional block diagram modeling environment, multi-port switch is provided to allow users to configure and deploy different configurations for a given module. FIG. 1B depicts an exemplary model 2000 that includes a multi-port switch block 2010. The multi-port switch block 2010 allows users to switch between different sources, such as Constant, Sine Wave, Modulator, and From Workspace, of a computational module.
The multi-port switch 2010 does have the advantage of being able to implement various configurations as cascaded blocks. However, the multi-port switch block 2010 is mainly designed to allow users to switch between different operating modes in a model at execution time. Consequently, it has certain drawbacks when it is utilized in contexts where users are attempting to switch between different model configurations prior to block diagram execution:
1. To allow for run-time switching between modes, all the blocks in the input branches of a switch are generally included in the compiled and linked versions of the model. This adds a significant performance overhead at the time of block diagram execution. While attempts have been made to optimize away inactive branches of the Switch at the time of execution, these attempts need complex analysis, are not always successful, and still require all of the configurations to be in memory simultaneously.
2. Users can not save away only the active configuration.